When you should not commission software
The cases where a subscription is the right answer, written down so we can point at them on calls instead of arguing.
Most businesses should not build
We build internal software for a living and we still tell people not to, regularly. It is a bad trade more often than the industry admits, and the cases where it is bad are predictable enough to write down.
One location, one calendar, nobody retyping
If the whole operation books through one calendar, the customer record lives in one place, and no member of staff is copying information between systems, a product subscription is correct. Buy the good one and stop thinking about it.
The case for building starts when work crosses tools, not when a tool is imperfect.
You need it next week
Nothing custom is ready next week. If there is a deadline that close, buy something now. Building later is still available, and you will scope it better having used something first.
Nobody can say what it should do
If the business cannot describe its own process without three people disagreeing, custom software will encode the disagreement. Off-the-shelf software imposes a process, and for a business that has not settled on one, that constraint is a feature.
Come back when the arguments are resolved, or resolve them first with a smaller change.
The tool is genuinely doing its job
A tool that works and is priced sanely should be connected to, not replaced. We do this on nearly every build. Replacing something that works to make our own scope look bigger is how a project becomes expensive without becoming better.
What tips it the other way
Three or more tools holding versions of the same customer. Staff whose job includes moving data by hand. A per-seat bill growing faster than the team. A process that is genuinely yours and that no product supports.
If none of those apply, keep your subscriptions. We will say so on the call.